home *** CD-ROM | disk | FTP | other *** search
/ CU Amiga Super CD-ROM 6 / CU Amiga Magazine's Super CD-ROM 06 (1996)(EMAP Images)(GB)(Track 1 of 4)[!][issue 1997-01].iso / cucd / online / fidonetts / fsc-0064.007 < prev    next >
Text File  |  1992-05-10  |  10KB  |  287 lines
  1. Document: FSC-0064
  2. Version:  007
  3. Date:     10-May-1992
  4.  
  5.  
  6.  
  7.  
  8.                 InterDomain Message Identification, Gating,
  9.                       Reply Linking and Addressing
  10.                              Jamie Penner
  11.                               1:153/1025
  12.  
  13.  
  14.  
  15.  
  16. Status of this document:
  17.  
  18.      This FSC suggests a proposed protocol for the FidoNet(r) community,
  19.      and requests discussion and suggestions for improvements.
  20.      Distribution of this document is unlimited.
  21.  
  22.      Fido and FidoNet are registered marks of Tom Jennings and Fido
  23.      Software.
  24.  
  25.  
  26.  
  27.  
  28.                Copyright (C) 1990, 1991, 1992 by Jamie Penner
  29.                            All Rights Reserved
  30.  
  31.                      Originally written:  Sept 3, 1990
  32.                         Revised:  November 12, 1990
  33.                           Revised:  June 23, 1991
  34.                          Revised:  August 26, 1991
  35.                         Revised:  January 22, 1992
  36.                         Revised:  February 4, 1992
  37.                         Revised:  February 12, 1992
  38.  
  39.  
  40.  
  41.  
  42. Use of this proposal is encouraged and permitted by the author without
  43. further notification in any software which is being written to conform
  44. to FTSC specifications.
  45.  
  46. Suggestions and discussion are strongly encouraged.   The author may be
  47. reached at:
  48.  
  49.  
  50.               jamie.penner@f1025.n153.z1.fidonet
  51.               jamie.penner@f0.n24.z24.signet.admin
  52.  
  53.  
  54.  
  55.  
  56.  
  57. Echomail Basics:
  58.  
  59.         All echomail passing through an interdomain echomail gateway
  60.         must have all information in the message header changed to
  61.         reflect the proper address of the domain in which the messages
  62.         are entering.   The PATH and SEEN-BY lines should also reflect
  63.         these changes with only the SEEN-BY line containing any
  64.         information from the domain previous.   This information shall
  65.         be the single address of the system passing the mail to the
  66.         gateway system.    In addition, all gateway software should
  67.         recognize, by the message itself, whether it has EVER passed
  68.         through the gateway in the past.   CRC records, SEEN-BY lines,
  69.         PATH lines and MSGID lines are not sufficient for this purpose
  70.         as most systems purge recorded logs of this info after a given
  71.         time.
  72.  
  73.  
  74.  
  75.  
  76. InterDomain Echomail/Netmail Flags:
  77. -----------------------------------
  78.  
  79.  
  80. ^ADOMORG: usr.nme@[!][p.f.n.z.]network[.nid][[#nodelist_name][#point[x]]
  81. ^ADOMDES: usr.nme@[!][p.f.n.z.]network[.nid][[#nodelist_name][#point[x]]
  82.  
  83.  
  84.  
  85.         These lines would be a complete domain signature for any user on
  86.         any system in any FTN network.
  87.  
  88.         The DOMORG line would be the actual origin information of the
  89.         user and system sending the information.
  90.  
  91.         The DOMDES line would be the actual destination information of
  92.         the recipient user and system.
  93.  
  94.         There are essentially two variations to the domain signature.
  95.         The ! immediately following the @ denotes a Type B, otherwise
  96.         defaulting to Type A.
  97.  
  98.         Type A:
  99.  
  100.                 e.g.  jamie.penner@f1025.n153.z1.fidonet
  101.  
  102.                 This has the complete FTN information needed for any
  103.                 processor to send the message.
  104.  
  105.         Type B:
  106.  
  107.                 e.g.  jamie.penner@!signet.admin#ic.signet
  108.  
  109.                 The ! immediately preceeding the network signifies that
  110.                 no FTN information is available but the information
  111.                 after the # will give the name of the system as denoted
  112.                 in the nodelist for that network.   This way, processors
  113.                 can be designed in a fashion that they can look up the
  114.                 system name.    Should this be going to a point, the
  115.                 domain may be:
  116.  
  117.                 jamie.penner@!signet.admin#ic.signet#point
  118.  
  119.                 If I have two points and I want to send it to a
  120.                 different point, I might use:
  121.  
  122.                 jamie.penner@!signet.admin#ic.signet#point2
  123.  
  124.                 The domain identifier in a Type B signature can be
  125.                 further used for further locating a system if needed.
  126.                 In both signature types, the nid (network identifier) is
  127.                 optional (eg fidonet.org or signet.admin - only the
  128.                 first field actually identifies the network name).
  129.                 This information is completely dependant upon each
  130.                 domain.   For example I might send this:
  131.  
  132.                 rob.macare@!signet.eur.r331#maasstad.bbs
  133.  
  134.                 This kind of structure would get the message to the
  135.                 right system.   If there was two of the same system in
  136.                 Region 331, I could use:
  137.  
  138.                 rob.macare@!signet.eur.n4601#maasstad.bbs
  139.  
  140.         This format of domain signatures is provided solely for
  141.         compatibility purposes to provide software developers with a
  142.         platform on which they can structure new programming techniques
  143.         and can be used in conjunction with the other flags as laid out
  144.         in this document.
  145.  
  146.  
  147.  
  148.  # GateOrigin: zzz:NNN/nnn.ppp@dmn    (note leading space)
  149.  
  150.         This line is currently inserted into all stripped down echomail
  151.         passing through interdomain gateways by GateWorks.   This allows
  152.         the message overhead to be cut down by properly replacing the
  153.         origin line for users to read in the text yet, not creating a
  154.         second full originline.   This line shall be added immediately
  155.         before the tearline with a single blank line following it.
  156.  
  157.         e.g.    # GateOrigin: 24:24/0.0@signet
  158.  
  159.  
  160.  
  161. ^AGATECHK: zzz.NNN.nnn.ppp [zzz.NNN.nnn.ppp] [zzz.NNN.nnn.ppp]
  162.         Any echomail passing through a particular gateway should have
  163.         this line inserted at the beginning of the message text.
  164.         Everytime the message passes through another echomail gateway,
  165.         the address would be added to the line.   This way, if a message
  166.         passes back through with the same ID, it is a known duplicate
  167.         and can be vaporized.
  168.  
  169.         e.g.    ^AGATECHK: 24.24.0.0 8.8.7001.0
  170.  
  171.  
  172.  
  173. ^AMSGORG: <originating-address> <originating-ID>
  174.  
  175.         The MSGORG line keeps a standard original address and message id
  176.         in the message for reply, identification, dupe checking, and
  177.         origination purpose.    This line would vanish and be replaced
  178.         with the necessary lines if passed through a gateway.
  179.  
  180.         e.g.    ^AMSGORG: 24:24/0.0@signet 0123456789abcdef
  181.  
  182.         The originating ID is no different than other 16 bit IDs being
  183.         generated.   It must be unique in a sense that no other message
  184.         originating from that system will have the same number (at least
  185.         within a short time span).
  186.  
  187.  
  188.  
  189. ^AGATEWAY: <zonegate-address>
  190.  
  191.         This field is inserted by the packer.   The user-defined
  192.         zonegate fields give the message its destination to the zonegate
  193.         and may be routed through whatever channels to get there.
  194.  
  195.         e.g.    ^AGATEWAY: 1:153/1025.0@fidonet.org
  196.  
  197.  
  198.  
  199. ^GRPLY: <zonegate-address> <originating-address>
  200.  
  201.         When replying to a message, this line would be looked up so as
  202.         to find the actual message destination and give the system its
  203.         zonegate information.    If the message passes through a
  204.         gateway, the MSGORG line would be removed upon insertion of
  205.         this line.
  206.  
  207.         e.g.    ^AGRPLY: 1:153/1025@fidonet.org 24:24/0.0@signet
  208.  
  209.  
  210.  
  211.  
  212. An example echomail message from 24:11/7777.0@signet across the domain
  213. to 1:153/85.0@fidonet should read:
  214.  
  215.  
  216. To: Bill Herringshaw, 1:153/85.0@fidonet
  217. From: Jamie Penner, 1:153/1025.0@fidonet
  218. Subject: Testing
  219. AREA: TEST_ECHO
  220. ^AGATECHK: 24.24.0.0
  221. ^AGRPLY: 1:153/1025.0@fidonet 24:11/7777.0@signet
  222. ^ADOMORG: jamie.penner@f7777.n11.z24.signet.admin
  223. ^ADOMDES: bill.herringshaw@f85.n153.z1.fidonet.org
  224. ^APID: RA 1.01
  225.  
  226. Hi Bill, just testing out this new software
  227.  
  228.  
  229.  # GateOrigin: 24:11/7777.0@signet
  230.  
  231.  --- GateWorks v4.00a
  232. * Origin: Home of GateWorks!! (1:153/1025.0)
  233. SEEN-BY: 24/0 153/1025
  234. ^APATH: 153/1025
  235.  
  236.  
  237.  
  238.  
  239. An editor programmed to handle these fields would recognize GRPLY line
  240. and know that the message had passed through a gateway.    An echomail
  241. reply would simply pass through the gateway.   If a netmail reply was
  242. required, this would be the reply message:
  243.  
  244.  
  245. To: Jamie Penner, 24:11/7777@signet
  246. From: Bill Herringshaw, 1:153/85.0@fidonet
  247. Subject: Testing
  248. ^AGATEWAY: 1:153/1025.0@signet
  249. ^AGRPLY: 24:24/0.0@signet 1:153/85.0@fidonet
  250. ^ADOMORG: bill.herringshaw@f85.n153.z1.fidonet.org
  251. ^ADOMDES: jamie.penner@f7777.n11.z24.signet.admin
  252.  
  253.  
  254. > Hi Bill, just testing out this new software
  255.  
  256.  
  257. Got it here!
  258.  
  259.  
  260. via InterMail @ 24:24/0.0@signet, 17:23:17  22 Jan 92
  261.  
  262.  
  263. The mailer and/or packer would check for the GATEWAY flag and route the
  264. message through that gateway.
  265.  
  266.  
  267. Under this method of flags, all systems in all domains should have
  268. access to the ability to reply via netmail to a system in a different
  269. domain.    In addition, by following this specification, all interdomain
  270. echomail should be clean and troublefree.   This eliminates the need for
  271. some of the other ^A lines being used.
  272.  
  273. It is the intention that all addresses in these flags may use the 5d
  274. addressing scheme, or either of the Type A or B domain signatures.   The
  275. software should be written to determine the type of address used and
  276. manipulate the situation accordingly.
  277.  
  278. The following list of software may be incomplete but lists all software
  279. currently available or under development using this spec:
  280.  
  281.         GateWorks v4.00
  282.         ContactBBS
  283.         TOSSworks
  284.         FASTmail
  285.  
  286. <EOF>
  287.